Converting command units into workflow activities

ABSTRACT

One or more available command units can be represented with a computer output device. The available command units can be command units from one or more snapins, such as one or more snapins that include command units to be run with a shell application. User input can be received from an input device, the user input selecting one or more selected command units of the available command units. In response to the user input, source code can be automatically generated from the one or more command units, and the source code can be automatically compiled to generate one or more workflow activities.

BACKGROUND

The complexity of computer management systems and management-relatedprocesses has reached new heights, making it difficult for informationtechnology (IT) professionals and administrators to achieve the processmaturity that will result in improved IT service levels, increasedresponsiveness to the needs of businesses, and increased IT efficiency.Organizations are outgrowing the basic job scheduling capabilities ofdisparate software products.

Workflow creation platforms and workflow engines have been provided toaddress this need. A workflow creation platform provides a framework forcreating workflows, including describing workflows and their behavior. Aworkflow engine executes workflows. For example, a workflow engine caninclude services for scheduling or triggering workflows, capturing theexecution history and output from workflows, and managing the lifetimeof workflows. There may be multiple different workflow engines that canfacilitate the execution of workflows created or edited with aparticular workflow creation platform. A workflow engine and a workflowcreation platform may be incorporated in a single product orapplication, or they may be one or more separate products orapplications.

A workflow defines relationships between units of work, which arereferred to herein as “activities.” For example, activities can be humanactivities (which are performed primarily by humans) or systemactivities (which are performed primarily by computer systems). A singleworkflow may include only human activities, only system activities, orboth human and system activities. Often, activities can be reused inmultiple workflows. Information technology professionals who createworkflows typically use a library of such activities when creatingworkflows.

Using current tools in the industry, development of workflow activitiesis often a complicated task, and it can take a significant amount oftime. Because of the complexity, developing workflow activities istypically done by developers, who often must manually enter the sourcecode for activities.

Command shell applications, such as command line shells and graphicaluser interface (GUI) shells, are sometimes used to allow the entry ofcommands and to invoke corresponding command units. An application mayprovide a command unit snapin (a collection of one or more commandunits) to automate administrative tasks. Such a snapin can include a setof one or more command units to be invoked by a shell application.Entering command shell commands is typically not as complex asdeveloping workflow activities. Thus, developers are typically notneeded to enter command shell commands; rather, IT professionals cantypically enter commands into command shell applications to invokecorresponding command units.

SUMMARY

It would be useful to have a simple way for users, such as informationtechnology professionals, to transform shell command units into workflowactivities. The described embodiments can fill this need.

In one embodiment, one or more available command units that can beexecuted through a shell application can be represented with an outputdevice. User input can be received from an input device, the user inputselecting one or more selected command units of the available commandunits. In response to the user input, source code can be automaticallygenerated from the one or more command units, and the source code can beautomatically compiled to generate one or more workflow activities.

In another embodiment, one or more available snapins can be represented,and a user input selecting one or more selected snapins of the one ormore available snapins can be received. One or more command units fromthe one or more selected snapins can be represented, and user inputselecting one or more selected command units of the one or morerepresented command units can be received. In addition, one or moreworkflow activities can be generated from the one or more selectedcommand units.

In yet another embodiment, an indication of one or more selected commandunits to be converted to one or more workflow activities can bereceived. One or more workflow activities can be generated from the oneor more selected command units. The one or more workflow activities canbe configured according to a workflow creation platform. Additionally,the one or more workflow activities can be configured to be executed byany of a plurality of different workflow engines that support theworkflow creation platform.

This Summary is provided to introduce a selection of concepts in asimplified form. The concepts are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used to limit the scope of the claimed subject matter.Similarly, the invention is not limited to implementations that addressthe particular techniques, tools, environments, disadvantages, oradvantages discussed in the Background, the Detailed Description, or theattached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a suitable computing environment in whichone or more of the described embodiments may be implemented.

FIG. 2 is block diagram of a computing environment for generatingworkflow activities from command units.

FIG. 3 is a flow diagram illustrating a technique for generating andusing workflow activities.

FIG. 4 is a flow diagram illustrating a technique for converting commandunits to workflow activities.

FIG. 5 is an illustration of a display area for displaying a list ofavailable snapins.

FIG. 6 is an illustration of a display area for displaying a list ofavailable command units.

DETAILED DESCRIPTION

Described embodiments are directed to techniques and tools for improvedcreation of workflow activities. Such improvements may result from theuse of various techniques and tools separately or in combination.

Such techniques and tools may include converting a shell command unitinto a workflow activity, or stated another way, using a shell commandunit to generate a corresponding workflow activity. The describedembodiments provide a way to do this automatically and/or to do it in away that allows the activity to be used by any of multiple workflowengines that support a particular workflow creation platform.

Often, a converted activity can be used by any workflow engine thatsupports a particular workflow creation platform. One or more commandunits may be represented to a user, and the user may be able to selectone of the represented command units. For example, multiple command unitsnapins may be represented to the user, and if the user selects one ormore of the snapins, then the command units in the selected snapin(s)can be represented to the user. The user can then select one or morecommand units from the snapin(s) to be converted to workflow activities.In response to the selection, the selected command units can beautomatically converted to workflow activities. This conversion caninclude mapping properties from the command units onto properties forworkflow activities to generate source code for the activities usingthose mapped properties, and compiling the source code into workflowactivities. Those converted workflow activities can be used similarly toother workflow activities—users can include them in workflows and theycan be executed by workflow engines as part of those workflows withoutmodifying the workflow engine or supporting code. However, eachconverted workflow can include logic to invoke the original commandunit, so that when a converted workflow activity is executed, thecorresponding original command is invoked and executed.

It has been known to convert a shell command unit into a workflowactivity. However, it is believed that some known methods for suchconversions only automatically create some source code to be used in theconversion, rather than automatically creating the activitiesthemselves. Accordingly, it is believed that a user typically must entersome source code manually before using a compiler to compile the sourcecode into an activity. In addition, it is believed that some suchmethods create activities that can only be used with a specific workflowengine; they cannot be used with other workflow engines, even if thoseengines are compatible with the same workflow creation platform as thespecific engine.

In contrast to such prior techniques, the present tools and techniquescan provide one or more advantages that make conversion of command unitsto workflow activities more user-friendly. For example, the tools andtechniques described herein can automatically create workflow activitiesthat can be executed by multiple different workflow engines, such as byany workflow engine that is compatible with a particular workflowcreation platform.

One or more substantial benefits can be realized from the workloadactivity creation tools and techniques described herein. For example,workflow activities can be created by users who do not have theknowledge possessed by a typical software developer. As another example,workflow activities can be created automatically with little requiredtime or effort. As yet another example, workflow activities can becreated from command units using a workflow creation platform, and theworkflow activities can be used with any workflow engine that supportsthat workflow creation platform.

The subject matter defined in the appended claims is not necessarilylimited to the benefits described herein. A particular implementation ofthe invention may provide all, some, or none of the benefits describedherein. Although operations for the various techniques are describedherein in a particular, sequential order for the sake of presentation,it should be understood that this manner of description encompassesrearrangements in the order of operations, unless a particular orderingis required. For example, operations described sequentially may in somecases be rearranged or performed concurrently. Techniques describedherein with reference to flowcharts may be used with one or more of thesystems described herein and/or with one or more other systems.Moreover, for the sake of simplicity, flowcharts may not show thevarious ways in which particular techniques can be used in conjunctionwith other techniques.

I. Exemplary Computing Environment

FIG. 1 illustrates a generalized example of a suitable computingenvironment (100) in which one or more of the described embodiments maybe implemented. For example, one or more such computing environments canbe used to convert command units to workflow activities. Generally,various different general purpose or special purpose computing systemconfigurations can be used. Examples of well-known computing systemconfigurations that may be suitable for use with the tools andtechniques described herein include, but are not limited to, serverfarms and server clusters, personal computers, server computers,hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, programmable consumer electronics, networkPCs, minicomputers, mainframe computers, distributed computingenvironments that include any of the above systems or devices, and thelike.

The computing environment (100) is not intended to suggest anylimitation as to scope of use or functionality of the invention, as thepresent invention may be implemented in diverse general-purpose orspecial-purpose computing environments.

With reference to FIG. 1, the computing environment (100) includes atleast one processing unit (110) and memory (120). In FIG. 1, this mostbasic configuration (130) is included within a dashed line. Theprocessing unit (110) executes computer-executable instructions and maybe a real or a virtual processor. In a multi-processing system, multipleprocessing units execute computer-executable instructions to increaseprocessing power. The memory (120) may be volatile memory (e.g.,registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flashmemory), or some combination of the two. The memory (120) storessoftware (180) implementing the conversion of command units intoworkflow activities.

Although the various blocks of FIG. 1 and other figures described beloware shown with lines for the sake of clarity, in reality, delineatingvarious components is not so clear and, metaphorically, the lines wouldmore accurately be grey and fuzzy. For example, one may consider apresentation component such as a display device to be an I/O component.Also, processors have memory. The inventors hereof recognize that suchis the nature of the art and reiterate that the diagram of FIG. 1 ismerely illustrative of an exemplary computing device that can be used inconnection with one or more embodiments of the present invention.Distinction is not made between such categories as “workstation,”“server,”“laptop,” “handheld device,” etc., as all are contemplatedwithin the scope of FIG. 1 and reference to “computer,” “computingenvironment,” or “computing device.”

A computing environment (100) may have additional features. In FIG. 1,the computing environment (100) includes storage (140), one or moreinput devices (150), one or more output devices (160), and one or morecommunication connections (170). An interconnection mechanism (notshown) such as a bus, controller, or network interconnects thecomponents of the computing environment (100). Typically, operatingsystem software (not shown) provides an operating environment for othersoftware executing in the computing environment (100), and coordinatesactivities of the components of the computing environment (100).

The storage (140) may be removable or non-removable, and may includemagnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, orany other medium which can be used to store information and which can beaccessed within the computing environment (100). The storage (140)stores instructions for the software (180).

The input device(s) (150) may be a touch input device such as akeyboard, mouse, pen, or trackball; a voice input device; a scanningdevice; a network adapter; a CD/DVD reader; or another device thatprovides input to the computing environment (100). The output device(s)(160) may be a display, printer, speaker, CD/DVD-writer, networkadapter, or another device that provides output from the computingenvironment (100).

The communication connection(s) (170) enable communication over acommunication medium to another computing entity. Thus, the computingenvironment (100) may operate in a networked environment using logicalconnections to one or more remote computing devices, such as a personalcomputer, a server, a router, a network PC, a peer device or anothercommon network node. The communication medium conveys information suchas data or computer-executable instructions or requests in a modulateddata signal. A modulated data signal is a signal that has one or more ofits characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media include wired or wireless techniques implementedwith an electrical, optical, RF, infrared, acoustic, or other carrier.

The tools and techniques can be described in the general context ofcomputer-readable media. Computer-readable media are any available mediathat can be accessed within a computing environment. By way of example,and not limitation, with the computing environment (100),computer-readable media include memory (120), storage (140), andcombinations of the above.

The tools and techniques can be described in the general context ofcomputer-executable instructions, such as those included in programmodules, being executed in a computing environment on a target real orvirtual processor. Generally, program modules include routines,programs, libraries, objects, classes, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or splitbetween program modules as desired in various embodiments.Computer-executable instructions for program modules may be executedwithin a local or distributed computing environment. In a distributedcomputing environment, program modules may be located in both local andremote computer storage media.

For the sake of presentation, the detailed description uses terms like“determine,” “select,” “represent,” “generate,” “convert,” and “operate”to describe computer operations in a computing environment. These andother similar terms are high-level abstractions for operations performedby a computer, and should not be confused with acts performed by a humanbeing, unless performance of an act by a human being (such as a “user”)is explicitly noted. The actual computer operations corresponding tothese terms vary depending on the implementation.

II. Workflow Activity Creation Environment

Referring to FIG. 2, a workflow activity generation computingenvironment (200) will be described. The components of the computingenvironment (200) may be incorporated into, be run by, and/or interactwith other computing components, such as the components of the computingenvironment (100) discussed above.

A. Activity Generator

The computing environment (200) can include an activity generator (210),which can manage the conversion of one or more command units (such ascmdlets from the Windows PowerShell™ command line interface) into one ormore corresponding workflow activities (such as Windows WorkflowFoundation workflow activities).

B. Command Shell Runspace

The environment (200) can also include a command shell runspace (220),such as a runspace of the Windows Powershell™ command line interface.The command shell runspace (220) can access one or more availablecommand unit snapins (222) registered with the computing environment(200) (such as being registered on a local machine). Each snapin (222)includes one or more command units (224) (such as one or more cmdletsfor the Windows Powershell™ command line interface). This is illustratedin FIG. 2 with the command units (224) being within the snapins (222),and the snapins (222) being within the command shell runspace (220).

As indicated by the two arrows between the activity generator (210) andthe command shell runspace (220), the activity generator (210) caninteract with the command shell runspace (220) to request and receiveinformation about the snapins (222) and the command units (224). Theactivity generator (210) can use this information in generatingactivities from the command units (224), as discussed below. Forexample, the activity generator (210) can use this information todetermine what information needs to be obtained from a user at workflowdesign time to allow the activity to run properly as part of a workflow.The exchange of information between the activity generator (210) and thecommand shell runspace (220) can be done using one or more standardprogrammatic interfaces.

The activity generator (210) can make a request for the command shellrunspace (220) to return the names of all the snapins (222) that areregistered and available to the command shell runspace (220). Inaddition, for each snapin (222), the activity generator can make arequest for the command shell runspace (220) to return names and otherproperties of the command units (224) in one or more of the snapins(222).

C. User Interface

Pertinent information about the snapins (222) and command units (224)can be requested all at once, or pertinent information can be requestedfrom the command shell runspace (220) as it is needed, as determined byinput received from a user interface (226) (as indicated by the arrowfrom the user interface (226) to the activity generator (210)). Theactivity generator (210) can also send information to the user interface(226) to be displayed to a user (as indicated by the arrow from theactivity generator (210) to the user interface (226)). The userinterface (226) can include one or more user output devices and one ormore user input devices, such as those described above with reference toFIG. 1.

As an example, in response to user input from the user interface (226)invoking the activity generator (210), the activity generator (210) canrequest and receive from the command shell runspace (220) the names ofthe available snapin(s) (222). Those names can then be sent by theactivity generator (210) to the user interface (226). In response touser input from the user interface (226) selecting one or more of thesnapins (222), the activity generator (210) can request and receive fromthe command shell runspace (220) the names of the command units (224) inthe selected snapins (222). Additionally, in response to user input fromthe user interface (226) selecting one or more of the command units(224) to be converted to corresponding workflow activities, the activitygenerator (210) can request and receive from the command shell runspace(220) additional information about the selected command unit(s) (224).

D. Information Collected About Command Units

The following are examples of types of information or properties thatmay be collected by the activity generator (210) and the command shellrunspace (220) for each command unit (224) to be converted: the name ofthe command unit (224), a description of the command unit (224), helpcontext for the command unit (224), general parameters exposed by thecommand unit (224), individual parameters exposed by the command unit(224), and the types of the individual parameters exposed by the commandunit (224).

As an example, for cmdlets for the Windows Powershell™ command lineinterface that potentially have multiple parameter sets for each cmdlet,a cmdlet name (Name) can be collected for each cmdlet, and a name (Name)and default value (IsDefault) of each parameter set can be collected. Inaddition, information about each parameter in each parameter set can becollected. The information about each parameter can include a name ofthe parameter (ParameterName), a parameter type (ParameterType), aparameter help message (HelpMessage), an indication of whether theparameter is mandatory (IsMandatory), and an expected position of thecmdlet in a command line for executing the cmdlet (Position).

This parameter information can be useful for various purposes. Forexample, a parameter name can be useful to convey the name of theparameter to a user designing a workflow using a corresponding convertedworkflow activity so that the user can input appropriate information forthe parameter. A parameter name can also be included in a call made tothe command line interface (such as including the name immediatelypreceding the value for the parameter) to invoke an original cmdlet whena corresponding converted activity is executed. The position of aparameter can be useful so that a name and value for that parameter canbe included in an appropriate place in a call made to the command lineinterface to invoke the cmdlet when executing a corresponding convertedactivity. Similarly, a parameter help message can be useful in conveyinghelpful information to a user designing or running a workflow thatincludes a workflow activity converted from the cmdlet. The parametertype can be useful to ensure that information entered for the parameteris of a correct type, such as when a user is entering parameter valueswhen designing a workflow with a corresponding converted workflowactivity. An indication of whether a parameter is mandatory can beuseful to force a user to enter values for mandatory parameters, or toinvoke error messages if a user fails to do so. Of course, differenttypes of information could be collected in other implementations.

E. The Code Object Model and the Activity Source Component

Referring still to FIG. 2, the activity generator (210) can use a codeobject model (230), such the code object model referred to as the CodeDocument Object Model (also known as the Code DOM) available fromMicrosoft Corporation, to map the properties (typically metadata, suchas the kinds of metadata discussed above) of the command units (224)onto properties for workflow activities. The activity generator (210)can also use the code object model (230) to generate source code,producing an activity source component (236) in a source language thatcan be compiled by a standard compiler. For example, the activity sourcecomponent (236) can be a Microsoft .NET activity class in the C# sourcelanguage. The activity source component (236) can be stored in anactivity source storage area (238), such as a storage area on afilesystem.

Command units (224) can sometimes return objects having particulartypes, such as complex objects. Such objects may be serialized (such asbeing serialized by a module in the command shell runspace (220)) andreturned to workflow activities as serialized strings, rather than theobjects' original types. The activity generator (210) can generatesource code to be included in the activity source component (236) toreconstruct such serialized strings back to their original object type.That source code can be compiled into a helper utility in the activity.The helper utility can read the serialized string (such as a serializedXML string) and reconstruct the object (such as reconstructing aMicrosoft .NET complex object using .NET reflection). In somesituations, the reconstructed object may not include all the informationfrom the original object, such as if all the information in the originalobject was not serialized.

If the command units (224) are cmdlets for the Windows Powershell™command line interface, and the activity source component (236) is aMicrosoft .NET activity class in C# language, the cmdlet name can beused as the activity class name, and required namespaces can be includedappropriately. If the cmdlet has multiple parameter sets, then anenumeration can be created, with the name of each parameter set being amember of the enumeration. In addition, a mapping can be maintainedbetween each parameter set and the individual parameters within thatset. Each parameter can be exposed as a public property of anappropriate type (which can be taken from the ParameterType value in thecmdlet), and can be named appropriately, such as by prefixing anunderscore to the name of the cmdlet parameter. The name (ParameterName)and help message (HelpMessage) properties of each cmdlet parameter canbe set as the DisplayName and Description attributes of the publicproperties in the activity class. Other parameter-specific cmdletproperties, such as IsMandatory and Position can be set as customattributes of the public properties in the activity class. Appropriateoverridden methods of collecting and specifying information, such asuser-specified information, can also be created as part of the activityclass.

An error handler routine can also be generated as part of the activityclass. Such a routine can help to validate user input, the sequence ofparameters, and the mapping of parameter sets and parameters. Using thisroutine, error validation can occur during workflow design. For example,if a user does not specify a mandatory parameter when including aconverted workflow activity in a workflow, the user could get an errormessage. As another example, there can be a check to determine whetherparameters specified by a user are of an appropriate type (integer,etc.), and appropriate error handling routines can be followed, based onthose determinations. Alternatively, different error handling routinescould be implemented, or error handling routines could be omitted.

In addition to the mapped properties of the corresponding command unit(224), each activity source component (236) can include logic to executethe corresponding command unit. For example, the activity sourcecomponent (236) can include logic for initiating (if necessary) andcalling the command shell runspace (220) to run the correspondingcommand unit (224). This can include passing an appropriate command lineto the runspace, including a name and appropriate parameters for acommand unit (224) corresponding to a converted workflow activity beinginvoked as part of a workflow.

F. The Compiler and the Workflow Activity

Referring still to FIG. 2, a compiler (250) can compile each activitysource component (236) into a workflow activity (256), such as a systemworkflow activity in a format that can be used by a standard workflowcreation platform to create a workflow that includes the workflowactivity (256). For example, activity source components (236) can beincluded in a larger Microsoft Visual Studio project, which can becompiled using Microsoft Visual Studio. As another example, Microsoft'sCode DOM could be used to compile workflow activities (256) intoMicrosoft .NET assemblies.

The workflow activity (256) can be stored in an activity storage area(258), such as an appropriate storage area in a filesystem where it isavailable to an appropriate workflow creation platform. The workflowactivity (256) can then be included in workflows using an appropriateworkflow creation platform, such as Microsoft's Visual Studio softwareor a management pack authoring console that may be included in futurereleases of Microsoft's System Center Service Manager software. Thoseworkflows can be executed by standard workflow engines that support theworkflow creation platform.

The workflow activity (256) can include logic for initiating (ifnecessary) and calling the command shell runspace (220) to run thecorresponding command unit (224) when the activity is initiated as partof a workflow. Thus, the activity (256) can be thought of as a workflowactivity wrapper for the corresponding command unit (224), which allowsa standard workflow engine to run the workflow activity (256) andthereby invoke the corresponding command unit (224) as part of theworkflow. The activity (256) can also include logic for receivinginformation that is produced by the execution of the correspondingcommand unit (224). This information can be dealt with appropriately ina normal manner, such as storing it and/or displaying it to a user atthe conclusion of the execution of the activity (256), or the conclusionof the execution of the workflow.

III. Command and Workflow Techniques

A. Technique For Converting Command Units for Use in Workflows

Referring to FIG. 3, a general technique (300) for converting commandunits to workflow activities and using them in workflows will bedescribed. The technique illustrated in FIG. 3 and the techniquesdescribed below with reference to FIG. 4 may be carried out usingcomputing environments such as the ones described above with referenceto FIGS. 1 and 2, or using one or more other computing environments. Thetechnique (300) can include converting (310) command units to workflowactivities, such as .NET workflow activity assemblies or some other kindof workflow activity assemblies.

The converted activities can be used (320) to create workflows bydeclaring workflows that include the converted activities. The workflowscan also include other activities, including human and/or systemactivities. The use of the activities in creating workflows can be donein a typical manner with a standard workflow creation platform, such asMicrosoft's Visual Studio software or a management pack authoringconsole that may be included in future releases of Microsoft's SystemCenter Service Manager or some other workflow creation platform, so thatthe workflows using those activities can be executed (330) by any ofmultiple standard workflow engines that support the workflow creationplatform. Indeed, the workflows can typically be executed (330) by anysuch standard workflow engine that supports the corresponding workflowcreation platform.

During workflow execution (330), a converted workflow activity can beinvoked in a typical way, such as at a specified time or upon theoccurrence of a specified event in the course of the workflow. When theworkflow activity is invoked, the workflow engine can use logic in theconverted workflow activity to call a shell application for thecorresponding command unit. This call can instruct the shell applicationto initiate, if necessary, and to run the corresponding command unitaccording to specified parameters. For example, this can be done withstandard programmatic interfaces between the activity and the shellapplication, and parameters can be passed to the shell application withthe appropriate context and in the appropriate positions for the shellapplication. This context and these positions can be specified in theconverted activity (e.g., with the mapped versions of the parameterposition property and other properties for parameters for the commandunit). The shell application can return any results (e.g., data and/orerror messages) to the activity. For returned serialized strings, theactivity may reconstruct the original object types from the serializedstrings, as discussed above. The activity can in turn pass the results(including reconstructed objects) on to the workflow engine running theactivity using standard programmatic interfaces. The workflow engine canthen deal with the results appropriately, such as by displaying themwhen the workflow including the activity finishes running or using theresults as input to conditional logic functions to determine the nextactivity in a workflow.

B. Technique for Converting Command Units to Workflow Activities

Referring now to FIG. 4, a technique (400) for converting command unitsto workflow activities will be described. Command units can berepresented (410) to a user. There are many ways that this could be doneusing various user interface output devices. However, representing (410)the command units can include representing (412) one or more availablecommand unit snapins that each include one or more command units. Forexample, available snapins can be listed on a display area of a computerdisplay, as described below with reference to FIG. 5. A user input thatselects one or more of the snapins can be received (414), such as from auser input device. One or more command units in the selected snapin(s)can then be represented (416).

A user input that selects one or more of the represented command unitscan be received (420), such as from a user input device, and one or moreactivities can be generated or converted (430) from the command unit(s).Generating (430) one or more activities can be done in different ways.However, it can include retrieving (432) properties of selected commandunits. This could be done in a single call, in sequence as multiplecommands are selected, or in some other manner. As discussed above, theretrieved properties can include those that are desired for collectingneeded information, such as properties that define parameters to bereceived as user input when a workflow with the resulting activity isdesigned. The retrieved properties can also include those that aredesired for executing the resulting workflow activity and invoking acorresponding command unit when the activity is executed.

The retrieved properties can be used to generate (434) source code forworkflow activities. Generating (434) the source code can includemapping the retrieved properties to properties in a source language, andgenerating source code with appropriate context. For example, this canbe done using a code document object model, such as the Code DOMavailable from Microsoft Corporation. The generated source code, whichcan be an activity class such as a Microsoft .NET activity class in C#code, can be stored (436) in non-volatile storage, such as in afilesystem. Alternatively, the source code could remain in volatilememory, such as volatile RAM, and not be stored in non-volatile storage.The source code can be compiled (438) to form a workflow activity, suchas an activity based on Windows Workflow Foundation. For example,compiling (438) can be done with a standard compiler that can compile C#code.

The resulting converted workflow activity or activities can be stored(450), and can be used in designing workflows that use the activities,such as by using a standard workflow creation platform. Those activitiescan then be run with a standard workflow engine that supports theplatform, as discussed above.

C. Snapin Display

Referring to FIG. 5, a snapin display area (500), such as a display areaof a computer display, displays a list (510) representing availablesnapins that can be selected, as discussed above with respect torepresenting (412) snapins in FIG. 4. The selection of snapins could bedone in any conventional manner, such as by using a keyboard or apointing device to move a cursor over the list and selecting one or moredesired snapins by depressing a button on a keyboard or pointing device.The display area (500) can include buttons, which can be target areas ofa display, where a user can indicate a selection by hovering a pointerover the target area and making an indication such as a mouse click.Selection of a back button (520) can result in the display of a previousdisplay area, such as a display area that allows a user to make aselection to invoke the snapin display area (500). Selection of a cancelbutton (530) can cancel the operation and close the snapin display area(500). After selecting one or more snapins from the snapin list (510), auser can select a next button (540) to display a command unit displayarea (600) illustrated in FIG. 6.

D. Command Unit Display

The command unit display area (600) can display a list (610)representing available command units in the selected snapins, such asthe representing (416) discussed above with reference to FIG. 4. A usercan select one or more command units from the list (610) in the samemanner as selecting the snapins from the snapin list (510) illustratedin FIG. 5. The command unit display area (600) can also include a backbutton (620), which can be selected to return to the snapin display area(500) of FIG. 5. In addition, the command unit display area (600) caninclude a cancel button (630), which can be selected to cancel theselection of command units. Selection of a next button (640) on thecommand unit display area (600) can result in a computing environmentautomatically generating workflow activities from the selected commandunits, as discussed above. Alternatively, some additional user inputcould be requested. For example, the selected command unit(s) could beconverted to source code activity class(es) in response to selection ofthe next button (640), and an additional user input could prompt thecomputing environment to compile the source code activity class(es) intoworkflow activities.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A computer-implemented method, comprising: representing with anoutput device one or more available command units that can be executedthrough a shell application; receiving user input from an input device,the user input selecting one or more selected command units of theavailable command units; and in response to the user input:automatically generating source code from the one or more command units;and automatically compiling the source code to generate one or moreworkflow activities.
 2. The method of claim 1, wherein each of the oneor more workflow activities is configured to facilitate execution of acorresponding command unit through the shell application, each of theone or more workflow activities having been generated from itscorresponding command unit.
 3. The method of claim 1, wherein the one ormore workflow activities are configured to be run by any of a pluralityof different workflow engines.
 4. The method of claim 3, wherein theworkflow activities are configured according to a workflow creationplatform, and the workflow activities are configured to be executed byany workflow engine that supports workflows created with the workflowcreation platform.
 5. The method of claim 1, further comprising storingthe one or more workflow activities in computer storage.
 6. The methodof claim 1, wherein generating the source code comprises mappingproperties of the selected command units onto workflow activityproperties.
 7. The method of claim 6, wherein mapping comprises using acode document object model to map properties of the selected commandunits onto properties of the workflow activities.
 8. The method of claim1, further comprising using one or more of the generated workflowactivities to form one or more workflows and executing the one or moreworkflows.
 9. The method of claim 1, wherein at least one of the one ormore workflow activities is configured to produce a reconstructed objectfrom a serialized string, the reconstructed object being an object typethat is the same as an object type of an original object from which theserialized string was produced.
 10. The method of claim 1, whereinrepresenting the one or more available command units comprisesdisplaying one or more representations of one or more available snapins.11. The method of claim 10, wherein representing the one or moreavailable command units further comprises: receiving a user inputselecting one or more selected snapins of the one or more availablesnapins; and displaying one or more command units from the one or moreselected snapins.
 12. A computer system comprising: means forrepresenting one or more available snapins; means for receiving a userinput selecting one or more selected snapins of the one or moreavailable snapins; means for representing one or more command units fromthe one or more selected snapins; means for receiving user inputselecting one or more selected command units of the one or morerepresented command units; and means for generating one or more workflowactivities from the one or more selected command units.
 13. The systemof claim 12, wherein the means for generating the one or more workflowactivities comprises means for automatically generating the one or moreworkflow activities in response to the user input selecting the one ormore selected command units.
 14. The system of claim 12, wherein themeans for generating the one or more workflow activities comprises:means for generating source code from the one or more command units, themeans for generating source code including means for mapping propertiesof the one or more selected command units onto workflow activityproperties; and means for compiling the source code.
 15. The system ofclaim 12, wherein the workflow activities are configured to be executedby any of a plurality of different workflow engines.
 16. The system ofclaim 15, wherein the workflow activities are configured according to aworkflow creation platform, and the workflow activities are configuredto be executed by any workflow engine that supports the workflowcreation platform.
 17. One or more computer-readable media containingone or more programs, the one or more programs comprising instructionsthat are executable by a computer system to perform acts comprising:receiving an indication of one or more selected command units to beconverted to one or more workflow activities; and generating one or moreworkflow activities from the one or more selected command units, the oneor more workflow activities being configured according to a workflowcreation platform, and the one or more workflow activities beingconfigured to be executed by any of a plurality of different workflowengines that support the workflow creation platform.
 18. The one or morecomputer-readable media of claim 17, wherein the acts further comprisedisplaying on a computer display one or more representations of one ormore available command units that can be executed through a shellapplication, wherein the one or more available command units include theone or more selected command units.
 19. The one or morecomputer-readable media of claim 17, wherein receiving an indication ofone or more selected command units comprises receiving user input from auser input device.
 20. The one or more computer-readable media of claim17, wherein generating one or more workflow activities comprisesautomatically generating one or more workflow activities.